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Executive  Summary 

COMPUTER-AIDED  ACQUISITION  AND  LOGISTIC  SUPPORT 
GATEWAY  DEVELOPMENT 


The  Department  of  Defense  is  committed  to  applying  the  best  in  modern 
technology  to  improve  transfer  of  weapon  systems  technical  information  among  DoD 
organizations  and  weapon  systems  contractors.  To  foster  the  application  of  such 
technology,  DoD  established  the  Computer-aided  Acquisition  and  Logistic  Support 
(CALS)  steering  group.  The  CALS  communications  working  group  provides  advice 
and  assistance  to  the  steering  group  on  data  transmission  requirements  and  commu¬ 
nications  protocols.  An  earlier  Logistics  Management  Institute  (LMI)  study  for  the 
CALS  working  group  made  specific  recommendations  and  presented  a  plan  to  use  and 
implement  the  Open  Systems  Interconnection  (OSI)  standards  for  CALS  telecommu¬ 
nications.  The  CALS  Telecommunications  Plan*  addresses  near-,  mid-,  and  long¬ 
term  gateway  activities.  This  report  explores  in  more  detail  how  near-  and  mid-term 
gateway  technologies  make  possible  direct  data  communications  among  diverse 
hardware  configurations.  These  gateways  will  facilitate  the  location,  collection,  and 
analysis  of  data  across  heterogeneous  computer  systems  and  data  networks. 

The  analysis  resulted  in  the  following  conclusions: 

•  All  CALS  data  communications  solutions  must  use  the  Government  Open 
Systems  Interconnection  Profile.  At  the  same  time,  communications  among 
systems  operating  with  the  existing  DoD  protocol  suite  must  be  maintained 
for  the  next  7  to  10  years. 

•  Gateway  functionality  for  all  but  the  simplest  text  transmissions  should  be 
placed  on  the  users’  local  area  network  or  within  their  host  machines. 
Placing  the  gateway  on  a  wide-area  network  would  result  in  poorer  system 
response  to  the  user. 

•  The  simplest  CALS  specification  to  implement  e  Standard  Generalized 
Markup  Language  (SGML)  for  sending  text.  Computer  Graphics  Metafile 
(CGM)  and  raster  graphics  follow  in  order  of  increasing  difficulty  and  are 
necessary  for  the  graphics  that  accompany  the  text.  The  Initial  Graphics 
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Exchange  Specification  (IGES)  is  third,  since  ambiguities  remain.  The 
Product  Data  Exchange  Specification  (PDES)  is  still  in  progress  and  will  be 
implemented  after  the  others. 

•  CALS  implementation  would  be  accelerated  by  quick  resolution  of  the 
ambiguities  in  CALS  data  format  standards,  as  uncovered  by  the  CALS  Test 
Network.  Refining  these  standards  will  reduce  the  need  for  gateways 
tailored  to  particular  implementations  of  each  CALS  standard. 

•  Intelligent  gateway  efforts  to  date  have  typically  involved  lower  volumes  of 
data  than  envisioned  under  CALS.  As  CALS  matures,  more  information 
will  be  available  for  electronic  transfer,  including  the  larger  data  files 
associated  with  engineering  drawings. 

•  To  help  define  CALS  gateway  requirements,  each  Military  Service  and 
agency  must  provide  a  traffic  profile  of  their  anticipated  CALS  data  flow. 
Government  network  planners  need  to  factor  these  requirements  into  their 
data  communications  planning  along  with  the  Electronic  Data  Interchange 
(EDI)  and  the  Modernization  of  Defense  Logistics  Standard  Systems 
(MODELS)  efforts.  These  CALS  profiles  will  provide  the  rationale  for 
higher  data  transmission  rates. 

LMI  recommends  that  CALS  participants  implement  gateway  capabilities  in 
the  following  order:  OSI/DoD  gateway,  SGML,  CGM  and  raster  graphics,  access  to 
high-speed  data  networks,  IGES,  and  PDES.  The  order  is  based  on  the  multiple 
protocol  suites  on  data  networks,  the  need  to  start  with  relatively  simple  textual  data 
and  progress  to  more  complex  graphics  and  manufacturing  data,  and  the  requirement 
for  higher  data  speeds  before  larger  files  can  be  sent  quickly.  Implementation  of 
these  gateway  capabilities  is  a  critical  step  in  achieving  the  interoperability  and 
standardization  goals  of  the  CALS  program. 
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SECTION  1 


INTRODUCTION 


1.1  BACKGROUND 

The  Department  of  Defense  is  committed  to  applying  the  best  in  modern 
technology  to  improve  transfer  of  weapon  systems  technical  information  among  DoD 
organizations  and  weapon  systems  contractors.  To  foster  the  application  of  such 
technology,  DoD  established  the  Computer-aided  Acquisition  and  Logistic  Support 
(CALS)  steering  group.  The  CALS  communications  working  group  provides  advice 
and  assistance  to  the  steering  group  on  data  transmission  requirements  and  commu¬ 
nications  protocols.  The  working  group  focuses  on  communications  requirements  for 
transferring  CALS  data  within  DoD  and  between  DoD  and  contractors. 

Earlier  work  by  LMI  for  the  working  group  made  specific  recommendations  and 
provided  a  telecommunications  plan  to  implement  the  Open  Systems  Interconnection 
(OSI)  standards  for  CALS  telecommunications.  Section  3  and  Appendices  C,  D,  and  E 
of  the  CALS  Telecommunications  Planl  discuss  near-,  mid-,  and  long-term  gateways. 
This  additional  effort  is  in  the  use  of  near-  and  mid-term  intelligent  and  communi¬ 
cations  gateway  technologies  to  allow  use  of  diverse  hardware  and  software  to  obtain 
direct  data  communications.  Gateways  facilitate  the  location,  collection,  and  analy¬ 
sis  of  data  across  heterogeneous  computer  systems  and  data  networks. 

Gateway  technology  will  accelerate  achieving  the  planned  CALS  benefits  as 
they  have  been  stated,-  including  the  following: 

•  Reduced  acquisition  and  support  costs  through  elimination  of  duplicative, 
manual,  error-prone  processes 
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•  Improved  quality  and  timeliness  of  technical  information  through  the  direct 
coupling  to  engineering  design  systems  and  databases 

•  Im;  ed  responsiveness  of  the  industrial  base  by  the  development  of 
im<-  =  .  ated  design  and  manufacturing  capabilities  and  by  industry  networks 
to  build  and  support  weapon  systems  based  on  digital  product  descriptions. 

DoD  will  realize  these  benefits  as  the  functional  integration  depicted  in  Figure  1-1 
evolves. 

1 .2  REPORT  ORGANIZATION 

This  report  assesses  the  components  involved  in  CALS  data  communications 
and  the  status  of  intelligent  and  communications  gateway  efforts.  A  near-  to 
mid-term  candidate  joint  Military  Service  gateway  strategy  is  recommended  to  meet 
the  CALS  requirements. 

Data  communications  in  the  CALS  environment  serves  as  the  starting  point 
and  is  discussed  in  Section  2.  The  requirements  for  connecting  a  variety  of  systems 
and  for  transferring  a  high  volume  of  data  are  addressed.  The  data  formats  and  data 
transfer  protocols  used  within  CALS  are  summarized.  Present  and  planned  commu¬ 
nications  facilities  available  to  Government  users  are  examined. 

Current  gateway  approaches  and  implementations  are  presented  in  Section  3. 
Four  different  types  of  gateways  are  reviewed.  This  discussion  provides  the  baseline 
for  discussing  gateway  implementations  in  the  CALS  environment. 

Potential  CALS  gateway  applications  are  presented  in  Section  4  based  on  the 
requirements  developed  in  the  earlier  sections.  Examples  are  given  of  various 
interconnection  schemes  to  furnish  on-line  data  transfer  capability.  The  gateway 
functions  of  command  translation,  format  conversion,  analysis,  and  data  network 
connectivity  are  explained. 

The  final  section  presents  the  conclusions  and  the  recommendation  for  a  joint 
Military  Service  gateway  strategy  to  meet  the  CALS  requirements. 


SECTION  2 


CALS  REQUIREMENTS 


Gateways  in  the  CALS  environment  must  communicate  across  a  wide  variety  of 
computer  systems  and  ha.  ale  a  large  volume  of  information.  These  needs  stem  from 
the  three  highest  priority  areas  within  CALS  for  DoD  systems: 

•  Architectural  planning  to  link  DoD  islands  of  automation  and  to  interface 
with  industry 

•  Equipping  automated  engineering  data  repositories  with  the  capability  for 
digital  input  to  support  spares  procurement  and  sustaining  engineering 

•  Providing  for  digital  input  to  automated  publishing  and  paperless  technical 
manual  systems. 

2.1  MANDATED  FORMAT  SPECIFICATIONS 

One  solution  for  providing  a  data  communications  capability  among  the 
Services,  agencies,  and  vendors  is  to  install  the  same  equipment  configuration  at 
every  location.  However,  this  is  not  possible  since  DoD  has  a  large  investment  in  a 
diversity  of  installed  systems  and  a  desire  to  maintain  competition  in  industry  for 
future  procurements.  Instead,  DoD  has  specified  a  common  format  for  representing 
the  data  in  Military  Standard  (MIL-STD)-1840A,  Military  Standard  Automated 
Interchange  of  Technical  Information.  This  standard  specifies  a  format  for  the 
interchange  of  logistics  information  between  computer  systems  in  the  support  of 
weapon  systems.  Table  2-1  crows  the  specifications  that  have  been  issued  for  each 
document  type. 

DoD  established  the  CALS  Test  Network  (CTIS )  to  test  these  specifications.  The 
Air  Force  Logistics  Command  (AFLC)  Architecture  and  Technology  Division  and  the 
Lawrence  Livermore  National  Laboratory  (LLNL)  are  performing  the  tests. 

The  CTN  so  far  has  tested  the  Standard  Generalized  Markup  Language  (SGML) 
text  data  and  Initial  Graphics  Exchange  Specification  (IGES)-formatted  graphics 
data.  Text  transfer  test  results  indicate  that  production  quality  document  transfer 
can  be  achieved,  contingent  upon  the  addition  of  some  automated  quality  control 
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TABLE  2-1 


CALS  SPECIFICATIONS 


Document  type 

Specification 

Text  data 

SGML  -  Standard  Generalized  Markup  Language 

MIL-M-28001 

Computer-aided  design  (CAD)  data 

IGES  -  Initial  Graphics  Exchange  Specification 

MIL-D-28000 

Graphics  without  CAD  data 

CGM  -  Computer  Graphics  Metafile 

MIL-D-28003 

Data  in  raster  format 

MIL-R-28002 

Product  data 

POES  -  Product  Data  Exchange  Specification 

In  progress 

tools  and  improved  reference  documentation.  The  transfer  of  graphics  using  the 
IGES  format  worked  well  except  for  the  type  fonts  in  the  text  callouts.  As  a  result, 
the  CTN  test  reports  recommend  that  IGES  type  font  specifications  be  strengthened, 
including  the  alphabet  size  and  set  width  specifications,  and  style  and  emphasis 
parameters. 

Until  the  CTN  thoroughly  tests  each  of  the  standards  and  the  National 
Institute  of  Standards  and  Technology  (NIST)  integrates  any  required  updates  into 
the  standards,  implementers  must  provide  intervening  steps.  These  steps  may  take 
the  form  of  specific  gateway  processors  for  each  type  of  system  or  manual  interven¬ 
tion  to  cleanup  the  documents  as  they  arrive.  The  gateway  would  compensate  for 
specific  deficiencies  or  differences  in  implementation  of  the  standards  between  two 
systems. 

The  specifications  cited  in  Table  2-1  describe  how  the  data  are  formatted.  Other 
standards  are  necessary  to  transmit  and  receive  these  data  across  a  variety  of 
machines.  Currently  in  use  within  DoD  is  the  Transmission  Control  Protocol/ 
Internet  Protocol  (TCP/IP)  suite.  DoD  implementations  after  August  1990  will  use 
the  Government  Open  Systems  Interconnection  Profile  (GOSEP)  suite.  Version  1  of 
the  seven-layer  OSI  architecture  is  shown  in  Figure  2-1.  GOSEP  Version  2  is 
scheduled  for  release  in  late  1989  and  will  add  Virtual  Terminal,  Office  Document 
Architecture,  and  Integrated  Services  Digital  Network  (ISDN)  specifications. 

I 
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Communications  between  existing  and  future  systems  running  the  two  different 
protocol  suites  is  one  gateway  function  discussed  in  Section  3.5. 


Notes:  "AM  =  A'le  Transfer  Access  and  Vianagement;  ACSE  =  Associative  Control  Service  E'entents;  CLNP  =  Connect  omess 
Network  Protocol;  PLP  =  Packet-Level  Protocol;  LlC  = -ogical  Link  Control;  CSMACD  =  Career  Sense  VluitiDie  Access  with 
Collision  Detection;  hdlC  =  Hign-level  Data  Link  Control.  LAP-8  =  Link  Access  Procedure-Baianced 

FIG.  2-1.  GOVERNMENT  OSI  ARCHITECTURE 
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2.2  HIGH  VOLUME  AND  TRANSMISSION  SPEED 


The  transition  to  a  paperless  environment  places  an  increasing  demand  on  the 
data  communications  facilities.  In  addition  to  text  files,  CALS  data  include 
engineering  drawings  which  result  in  a  large  file  when  represented  digitally.  An 
E-size  drawing  requires  more  than  8  Megabytes  (Mb).  Using  the  file  compression 
techniques  specified  in  MIL-STD-1840A,  a  20:1  reduction  is  achieved.  Assuming  a 
25  percent  overhead  for  handling  the  transmission,  1,500  drawings  would  require 
more  than  30  hours  to  send  across  a  56  Kilobytes  per  second  (Kbps)  line.  Sending  the 
same  1,500  drawings  would  require  a  little  over  1  hour  if  transmission  at  1.5  Mega¬ 
bytes  per  second  (Mbps)  were  available. 

The  high  volume  of  data  associated  with  transmitting  engineering  drawing 
information  drives  the  requirement  for  data  communications  speeds  higher  than 
56  Kbps.  High-speed  offerings  are  available  in  the  ISDN  and  Fiber  optic  Data  Distri¬ 
bution  Interface  (FDDI)  standards.  Dedicated  networks  constructed  of  1.5  Mbps  lines 
(Tl)  or  45  Mbps  (T3)  lines  are  also  an  option. 

ISDN  implementations  provide  a  set  of  voice  and  data  services  across  a  single 
integrated  network.  Data  transmission  rates  of  64  Kbps,  384  Kbps,  and  1.5  Mbps  are 
currently  provided.  Provisions  for  broadband  service  at  45  Mbps  and  150  Mbps  are 
under  study.  ISDN  services  are  now  offered  in  selected  regions  of  the  United  States. 

FDDI  is  a  fiber  optic  local  area  network  (LAN)  that  operates  at  100  Mbps. 
Useful  applications  include  interconnecting  several  high-speed  processors  located  in 
one  computer  room  or  nearby  rooms  and  buildings.  Multimode  fiber  is  specified.  This 
reduces  the  hardware  cost  by  replacing  lasers  with  cheaper  light  emitting  diodes 
(LEDs)  as  the  light  source.  FDDI  is  limited  to  2  kilometers  (km)  between  adjacent 
repeaters,  1,000  physical  connections,  and  a  total  fiber  path  of  up  to  200  km. 
However,  these  numbers  will  vary  based  on  the  configuration  Although  the  FDDI 
standard  is  still  in  draft  form,  equipment  based  on  a  final  FDDI  standard  should  be 
available  by  late  1989. 

Today,  long-distance  high-speed  data  transfers  are  accomplished  by  installing 
dedicated  facilities.  Dedicated  lines  provide  a  permanent  connection  between  the  two 
users,  even  when  no  data  are  being  transferred.  Therefore,  they  are  an  option  when 
the  traffic  between  two  points  is  high  and  reasonably  constant.  When  several 


56  Kbps  lines  between  two  specific  sites  are  full,  moving  to  a  1.5  Mbps  line  should  be 
considered. 

Data  communications  facilities  available  to  the  Government  user  are  discussed 
in  the  next  section. 

2.3  COMMUNICATIONS  FACILITIES 

2.3.1  Department  of  Defense 

The  two  major  DoD  inter-Service  data  communications  networks  are  the 
Defense  Data  Network  (DDN)  and  the  Defense  Commercial  Telecommunications 
Network  (DCTN).  DDN  is  the  mandated  data  communications  network.  DCTN  is 
procured  through  a  waiver  process.  Both  are  under  the  control  and  management  of 
the  Defense  Communications  Agency  (DCA). 

DDN  is  a  wide-area,  packet-switched  network  that  includes  about  1,500  hosts 
with  an  estimated  50,000  users.  The  maximum  data  rate  available  to  users  is  56 
Kbps.  Although  the  possibility  of  increasing  the  data  rate  across  some  of  the 
backbones  to  1.5  Mbps  is  under  review,  there  are  currently  no  plans  to  increase  the 
data  rates  at  the  user  interface.  Because  the  network  uses  the  TCPTP  and 
X. 25  standards,  these  protocols  must  also  be  resident  on  each  user’s  system  for 
connection  to  the  network.  Everyone  uses  the  File  Transfer  Protocol  (FTP)  for  file 
transfers  and  the  Simple  Mail  Transfer  Protocol  (SMTP)  for  electronic  mail.  All 
users  can  send  data  to  (and  receive  data  from)  any  other  user. 

DDN  users  will  be  billed  by  their  number  of  network  connections  and  the 
amount  of  data  sent  across  each  connection  beginning  in  October  1989.  The  projected 
tariff  for  the  DDN  service  is  shown  in  Table  2-2. 

DCTN  provides  switched  voice,  dedicated  voice  and  data,  and  video  communi¬ 
cations  for  DoD  operational  support  requirements  within  the  United  States.  These 
services  are  provided  by  American  Telephone  and  Telegraph  (AT&T)  under  a  fixed- 
rate  leased  services  contract  that  runs  through  February  1996. 
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TABLE  2-2 


PROJECTED  DDN  TARIFF 


Line  speed 

Hosts 

Terminals 

56/50  Kbps  single 

$2,200 

$300 

dual 

2,800 

390 

19  2  Kbps  single 

1,650 

300 

dual 

2,100 

390 

9  6  Kbps  single 

1,050 

300 

dual 

1,350 

390 

4.8  Kbps  single 

850 

300 

dual 

1,100 

390 

2.4  Kbps  single 

700 

300 

dual 

900 

390 

1.2  Kbps  single 

500 

300 

dual 

650 

390 

0.3  Kbps  single 

300 

300 

Dial-up  service 

7.5  cents  per  minute 

Traffic  charge  per 

Peak 

Off-peak 

kilopacket 

hours 

hours 

Precedence  1 

$1  35 

Precedence  2 

3.00 

Precedence  3 

4.00 

Precedence  4 

5.00 

5.00 

Notes:  single  =  single  access  to  DDN;  dual  =  dual  access  to  DDN, 
Precedence  1  -  4  *  the  priority  of  the  user's  traffic  with  Precedence  4  being 
the  highest  onority 


In  addition  to  terrestrial  facilities,  DCTN  includes  satellite  communications. 
The  15  nodal  locations  contain  a  digital  switch.  Nine  of  these  sites  have  a  commercial 
C-band  satellite  earth  station.  An  additional  13  nodes  are  to  be  offered  in  FY89.  The 
network  configuration  is  shown  in  Figure  2-2.  By  the  end  of  FY89,  DCTN  should 
have  an  estimated  9,600  switched  voice  access  lines,  280  dedicated  voice  circuits, 
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FIG.  2-2.  DCTN  LEVEL  II  NODAL  LOCATIONS 


680  dedicated  data  circuits  ^implying  1,360  data  users),  and  70  video  teleconferencing 
service  locations  on  the  network. 


DCTN  provides  nonswitched  data  services  at  4.8  Kbps,  9.6  Kbps,  56  Kbps,  and 
1.5  Mbps.  Because  these  are  dedicated  point-to-point  services,  addressing,  routing, 
and  error  correction  do  net  involve  higher  level  protocols  such  as  TCP/IP  and  X.25. 
Users  at  each  end  of  the  line  determine  the  telecommunications  protocols  used  to 
send  data  across  DCTN. 

The  provision  time  for  a  DDN  circuit  is  12  to  24  months.  A  new  circuit  on 
DCTN  requires  a  3-  to  6-month  leadtime.  DCTN  circuit  costs  are  based  on  the 
geographical  location  of  the  sites  connected,  rather  than  a  tariffed  approach. 

2.3.2  Federal  Telecommunications  System 

The  General  Services  Administration  (GSA)  awarded  the  Federal  Telecommu¬ 
nications  System  (FTS)-2000  contract  in  December  1988.  The  contract  award  was 
split  60/40  between  AT&T  and  US  Sprint,  with  AT&T  responsible  for  supporting 
DoD.  The  Boeing  Company,  Computer  Sciences  Corporation,  and  Sonicraft  Inc.  are 
teamed  with  AT&T. 

FTS-2000  services  will  be  available  in  early  1991  or  sooner  and  will  include 
switched  voice  service,  switched  data  service,  switched  digital  integrated  service, 
packet-switched  service,  electronic  mail,  video  transmission  service,  and  dedicated 
transmission  service.  The  switched  data  service  will  provide  synchronous,  full 
duplex,  digital  circuit-switched  service  at  56  Kbps  and  64  Kbps.  The  dedicated 
transmission  service  provides  the  same  service  on  a  continuous  basis,  plus  full  Tl 
facilities.  The  integrated  services  will  come  on  line  with  the  availability  of  ISDN. 
Under  ISDN,  all  the  services  listed  above  —  voice,  data,  and  video  transmissions  — 
are  combined  on  a  single  network.  The  allocation  of  each  circuit’s  capacity  is 
configured  dynamically  by  the  users  and  is  a  part  of  the  call  setup. 
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SECTION  3 


CURRENT  GATEWAY  APPROACHES  AND  IMPLEMENTATIONS 


This  section  reviews  a  sampling  of  current  gateway  approaches  to  achieve 
connectivity.  These  examples  provide  a  background  to  discuss  the  methods  available 
for  CALS.  The  first  example  is  the  Logistics  Information  Exchange  (LINX)  as 
proposed  by  the  Defense  Logistics  Agency  (DLA).  It  is  based  on  gateway  technology 
that  was  developed  at  LLNL  and  is  now  being  marketed  and  supported  by  Control 
Data  Corporation  (CDC).  This  technology  is  also  used  in  AFLC’s  Logistics  Data 
Information  System  (LOGDIS),  the  Air  Force  Aeronautical  Systems  Division’s 
Central  Datacomm  System  (CDS),  and  is  offered  as  an  option  under  the  Air  Force’s 
Standard  Multiuser  Small  Computer  Requirements  Contract  (SMSCRC)  with  AT&T. 
The  second  example,  Fast,  is  a  product  developed  by  the  University  of  Southern 
California’s  Information  Sciences  Institute  (USC/ISI).  It  has  been  used  for  the 
connectivity  required  in  automated  electronic  parts  ordering.  The  next  two  examples 
are  the  Naval  Supply  Logistics  Network  (NLN)  and  the  Defense  Automatic  Address¬ 
ing  System  Office  (DAASO)  network.  Both  networks  provide  for  data  transmission 
among  a  variety  of  systems.  The  final  example  describes  gateway  development 
efforts  under  way  at  NIST  supporting  the  transition  from  the  DoD  protocol  suite  to 
the  GOSIP.  The  NIST  gateways  should  allow  file  transfer  and  electronic  mail 
between  the  two  protocols  and  coexistence  of  the  two  on  the  same  network. 

3.1  LOGISTICS  INFORMATION  EXCHANGE 

DLA  is  pursuing  a  gateway  effort  in  the  LINX  program.  The  goal  of  LINX  is  to 
provide  an  agency  and  vendor  interface  for  Electronic  Data  Interchange  (EDI) 
communications.  LINX  will  incorporate  the  capabilities  of  the  Technology  Informa¬ 
tion  System  Program  (TISP)/Tntelligent  Gateway  developed  by  LLNL.  This  gateway 
is  now  being  marketed  and  supported  under  the  trade  name  of  ASCENT  by  CDC,  who 
worked  in  conjunction  with  LLNL.  Features  of  the  gateway  include 

•  Support  for  multiple  terminal  types  and  personal  computers  (PCs) 

•  Connectivity  to  multiple  noncompatible  hosts 
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•  Auto  log-in  to  multiple  noncompatible  hosts 

•  Capability  to  download,  reformat,  manipulate,  and  integrate  data. 

A  phased  approach  is  planned.  The  initial  step  integrates  the  current  vendor 
interfaces  [Paperless  Order  Processing  System  (POPS)  and  SAMMS1  Procurement  by 
Electronic  Data  Exchange  (SPEDE)]  into  an  automated  system.  Near-term  service 
capabilities  would  include  access  through  DDN,  dial  and  dedicated  services,  and 
Ethernet  LANs.  It  would  support  negotiated  EDI  formats,  American  National 
Standards  Institute  (ANSI)  X.12  formats,  and  valued-added  networks  (VANs).  In 
later  stages,  LINX  would  transition  toward  emerging  standards,  including  GOSIP. 
Because  many  communications  facilities  use  the  TCP/IP  suite  today,  TCPTP  would 
remain  as  an  option  when  GOSIP  becomes  available. 

3.2  FAST 

Fast  (sometimes  called  "Fast  Broker”)  is  a  computerized  system  for  the 
automatic  purchasing  of  standard  electronic  parts.  It  was  developed  at  USC/ISI 
under  the  sponsorship  of  the  Defense  Advanced  Research  Projects  Agency  (DARPA) 
and  AFLC.  Users  communicate  with  Fast  by  electronic  mail  to  request  technical 
information  and  quotes.  Customers  can  place  orders  that  are  Filled  by  overnight 
shipping.  Customers  then  reimburse  Fast  for  the  purchase. 

The  Fast  system’s  connection  to  on-line  vendors  is  depicted  in  Figure  3-1.  A 
Request  for  Quotation  (RFQ)  generates  an  RFQ  message  to  all  on-line  vendors  for 
that  product.  The  user  receives  the  vendors'  quotes  usually  in  minutes.  Technical 
information  and  parts  equivalence  information  can  also  accompany  the  vendors' 
quote.  When  necessary,  Fast  also  contacts  vendors  who  are  not  on  line.  The  Fast 
electronic  connection  meets  the  ANSI  X.12  standards. 

Fast  resides  at  USC/ISI  on  the  ARPANET/M3LNET/INTERNET2  network. 
Users  send  and  receive  messages  by  electronic  mail  via  Telemail  and  MCI  Communi¬ 
cation  Corporation  Mail. 


'Standard  Automated  Materiel  Management  System. 

2Advanced  Research  Projects  Agency  Network/Military  Network/INTERNET 
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Quotes 


DLA  is  testing  Fast  by  using  it  as  a  vendor  on  the  SPEDE  system  at  the  Defense 
Electronics  Supply  Center  (DESC).  SPEDE  uses  the  X.12  format  and  accesses  Fast 
over  a  dial-up  line. 

3.3  NAVAL  SUPPLY  SYSTEMS  COMMAND'S  LOGISTICS  NETWORK 

The  Naval  Supply  Systems  Command’s  (NAVSUP)  NLN  provides  telecommu¬ 
nications,  interactive  processing,  front-end  processing,  and  terminal  concentrator 
capabilities.  The  telecommunications  feature  provides  connectivity  for  the  inventory 
control  points  (ICPs),  stock  points,  and  specific  users  of  logistics  information. 
Hardware  has  been  installed  at  39  sites,  with  6  more  planned  for  1989,  as  shown  in 
Figure  3-2.  Currently,  NLN  supports  an  estimated  10,000  users.  Gateways  are  in 
place  or  planned  for  access  to  the  Defense  Logistics  Agency  Network  (DLANET), 
Defense  Automatic  Addressing  System  (DAAS),  Military  Airlift  Command  (MAC) 
Advanced  Transportation  Control  and  Movement  Document  System  (ATCMDS), 
Inventory  Locator  System  (ILS),  Technical  Logistics  Reference  Network  (TLRN),  and 
Haystack. 

Tandem  computers  serve  as  the  gateways.  Resident  on  the  Tandem  are  flat  file 
transfer  capabilities  for  accessing  other  Tandems  and  other  vendors’  equipment, 
including  IBM,  UNTVAC,  Burroughs,  and  Honeywell.  As  an  example,  the  Tandem 
computer  gateway  to  DLA  is  running  a  Systems  Network  Architecture  (SNA)  to  3270 
Bisync  conversion  to  communicate  with  the  COMM  TEN  on  DLA’s  side. 

Dedicated  contingency  lines,  as  shown  in  Figure  3-3,  rather  than  DDN  are 
currently  in  use  as  the  backbone  for  NLN.  The  exception  is  for  the  OCONUS3  sites  in 
Yokosuka,  Japan;  Subic  Bay,  Philippines;  and  Guam  which  are  accessed  through 
DDN.  The  dedicated  lines  primarily  operate  at  9.6  Kbps  to  19.2  Kbps. 

Plans  include  a  gateway  between  the  proprietary  Tandem  mail  protocol  and  the 
DoD  SMTP  for  communications  with  European  customers  and  transition  to  the  OSI 
protocols  when  they  become  commercially  available. 


^Outside  of  the  Continental  United  States 
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FIG.  3-2.  NLNDDN  CONNECTIVITY 


NAS  vVfi'Jt*-,  Hi. 


FIG.  3-3.  NLN  NETWORK  CONNECTIVITY 


3.4  DEFENSE  AUTOMATIC  ADDRESSING  SYSTEM 


DAAS  receives  and  routes  worldwide  logistics  traffic,  processes  logistics 
documents,  generates  activity  reports,  publishes  address  directories,  and  maintains 
large-scale  databases.  It  also  serves  as  a  central  facility  to  imolement  new  DoD 
logistics  procedures.  DAASO  resides  within  DLA. 

DAASO  operates  from  two  sites;  one  in  Dayton,  Ohio,  and  the  other  in  Tracy, 
California.  Each  site  uses  CDC,  Gould,  and  Zenith  computers.  CDC  1700  systems 
are  used  as  the  front-end  communications  processors  to  receive  and  transmit 
Automatic  Digital  Network  (AUTODIN)  message  traffic.  Each  of  the  two  DAASO 
sites  and  the  associated  AUTODIN  Switching  Centers  (ASCs)  are  linked  by  4.8  Kbps 
lines  as  shown  in  Figure  3-4.  The  messages  are  formatted  as  established  by  Joint 
Army,  Navy,  Air  Force  Procedures  (JANAJP)  128  AUTODIN  Operating  Procedures. 
DAASO  in  Dayton,  Ohio,  is  also  the  central  point  for  interfacing  with  the  Inter¬ 
national  Logistics  Communications  System  (ILCS).  The  two  are  connected  on  a  dial¬ 
up  basis.  The  systems  are  in  use  24  hours  a  dav.  7  days  a  week,  processing  more  than 
80  million  transactions  each  month. 

DAASO  is  currently  implementing  an  Automatic  Data  Processing  Equipment 
( ADPE)  Replacement  Program  plan  to  support  current  and  future  levels  of  service  to 
input  subscribers.  After  updating,  a  variety  of  transmission  paths  will  be  available 
including  AUTODIN.  DLANET,  NLN,  DDN,  ILCS.  dial-up  lines,  and  dedicated 
private  lines. 

3.5  OSI/DoD  NETWORK  INTEROPERABILITY 

GOSIP  Federal  Information  Processing  Standard  (FIPS)1 46,  released  in 
August  1988,  mandated  that  network  procurements  after  August  1990  conform  to  the 
specified  OSI  standards.  DCA  produced  a  transition  strategy  for  moving  from  the 
DoD  protocols  to  OSI.  The  plan  calls  for  coexistence  of  OSI  and  DoD  protocols  on 
shared  networks  and  the  capability  to  interoperate  between  the  two  protocol  suites. 
With  these  two  capabilities,  DoD  will  not  have  to  attempt  a  sudden  and  complete 
switchover  from  TCP'TP  to  GOSIP  protocols.  The  switchover  can  proceed  over  a 
period  of  7  to  10  years. 
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FIG.  3-4.  DAAS  AND  AUTODIN  SWITCHING  CENTERS 


Several  gateways  are  planned  for  the  initial  steps  in  transitioning  from  the 
current  DoD  protocol  suite  over  to  those  specified  by  GOSIP.  Interoperability  will  be 
achieved  by  implementing  File  Transfer  Access  and  Management  (FTAM).FTP  and 
X. 400/SMTP  gateways  in  the  Application  or  seventh  layer  of  the  OSI  model.  A 
Connectionless  Network  Protocol/Internet  Protocol  (CLNP/TP)  gateway  is  under 
development  to  aid  coexistence.  The  CLNP/IP  gateway  resides  above  the  Network  or 
third  layer  to  serve  as  an  internet  gateway.  Both  types  of  gateways  are  discussed  in 
more  detail  below. 

3.5.1  Application  Layer  Gateways 

Application  Layer  gateways  allow  users  to  communicate  across  the  different 
protocol  suites.  DoD  tasked  NIST  in  1986  to  develop  two  gateways  for  use  between 
OSI  and  TCP/IP.  The  prototype  FTAM/FTP  gateways  for  file  transfer  and  X.400/' 
SMTP  gateways  for  electronic  mail  are  currently  under  test  on  the  Open  Systems 
Interconnection  Network  (OSINET).  Developed  on  a  Digital  Equipment  Corporation 
MicroVax  II,  these  two  application  gateways  will  be  released  as  a  part  of  the  next 
Berkeley  UNIX  operating  system  version  in  December  1989. 

DCA  plans  to  provide  the  file  and  mail  gateways  on  the  DDN.  The  gateways  are 
dual  protocol  hosts  in  that  they  implement  the  full  OSI  and  DoD  protocols.  The 
gateway  software  translates  from  one  application  to  the  other  as  shown  in  Figure  3-5. 
The  application  gateways  will  be  placed  on  the  DDN  as  shown  in  Figure  3-6.  A  call 
from  an  OSI  host  to  a  DoD  host  would  be  routed  through  the  application  gateway  for 
the  translation.  However,  to  reduce  the  congestion  across  the  DDN,  the  gateway 
software  will  also  be  made  available  through  a  Berkeley  UNIX  release.  Then,  DoD 
users  can  implement  a  gateway  on  their  own  LANs  as  shown  in  Figure  3-7.  With  this 
capability  resident  locally,  fewer  calls  across  the  DDN  will  be  necessary.  The  calls  to 
the  gateway  will  be  made  across  the  LAN,  which  is  usually  operating  at  much  higher 
speeds  than  the  DDN.  DCA  recommends  for  all  but  the  occasional  user  that  the 
OSI/DuD  gateways  be  placed  on  users’  LANs.  Otherwise,  the  recurring  need  to  access 
the  gateways  on  the  DDN  will  produce  a  bottleneck  in  users’  data  communications. 

The  Application  Layer  gateway  allows  a  transition  period  for  updating  TCPTP 
systems  to  the  GOSEP.  However,  users  will  be  motivated  to  change  their  TCPTP 
systems  which  must  communicate  with  the  GOSEP  compliant  systems  coming  on  line, 
rather  than  relying  on  the  gateway.  The  gateway  slows  communications,  since  it 
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Notes:  TCP  *  Transmission  Control  Program;  TP-4  *  Transoort  Protocol  Class  4 


FIG.  3-5.  GATEWAY  ARCHITECTURAL  MODEL 


FIG.  3-6.  DON-BASED  GATEWAY 
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FIG.  3-7.  LAN-BASED  GATEWAY 

must  unpackage  the  TCP/TP  data,  map  it  between  the  different  mail  or  file  transfer 
protocols,  and  repackage  it  according  to  GOSIP. 

3.5.2  Connectionless  Network  Protocol/Internet  Protocol 

CLNP  is  the  OSI  counterpart  of  the  DoD  IP  at  the  Network  Layer.  CLNP 
provides  the  means  to  tie  together  subnetworks  based  on  the  different  lower  layer 
technologies  defined  by  GOSIP.  To  route  data  across  the  different  subnetworks, 
unique  names  are  used  to  identify  each  object  in  the  network.  OSI  name  and  address 
attributes  will  be  registered  through  NIST. 

To  interconnect  wide-area  networks  (WANs)  or  LANs  that  may  have  both  DoD 
and  OSI  hosts,  a  dual  gateway  is  required.  The  dual  gateway  would  provide  both  the 
CLNP  and  IP  and  is  located  as  shown  in  Figure  3-8.  The  gateway  does  not  translate 
from  one  protocol  to  the  other,  but  rather  lets  both  coexist  on  the  same  network 
interconnection.  The  CLNP  portion  is  required  to  internetwork  the  OSI  hosts.  The 
IP  half  allows  internetworking  of  the  DoD  protocol  hosts. 


FIG.  3-8.  CINP/IP  GATEWAY 
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SECTION  4 


POTENTIAL  CALS  GATEWAY  APPLICATIONS 


Gateways  can  provide  access  for  current  and  future  systems  through  cost- 
effective,  secure,  high-speed  data  communications  networks  —  both  commercial  and 
Government.  This  access,  while  systems  and  standards  are  evolving,  provides  a 
direct  data  connection  where  the  CALS  requirements  warrant  one. 

Potential  CALS  scenarios  are  based  on  the  different  combinations  of  formats, 
protocols,  and  networks  presented  in  Table  4-1.  For  example,  it  may  be  desirable  to 
send  drawings  between  two  particular  locations.  The  gateway  at  each  end  might 
support  transferring  drawings  in  the  IGES  format  by  using  the  GOSIP  protocol 
FT  AM  across  a  high-speed  WAN.  This  and  other  combinations  allowing  the  transfer 
of  an  IGES-formatted  drawing  are  shown  in  Figure  4-1. 


TABLE  4-1 
CALS  ELEMENTS 


Information  format 

Text:  SGML 

Drawings:  IGES/raster/CGM 

Productdata:  PDES 

File  Transfer  Protocol 

FTP  or  FTAM 

Network 

LAN,  WAN,  or  combination  of  the  two 

(Votes:  CGM  =  Computer  Graoh|cs  Metafile,  POES  =  Product  Data  Excnange  Soecification 


The  combinations  are  varied  and  implementation  can  prove  difficult.  Gateways 
serve  to  fill  in  the  gaps  between  dissimilar  systems.  Sending  information  in  the 
SGML  or  IGES  format  requires  intervention  to  reformat  the  data  and  to  make 
implementation  decisions  where  the  standards  are  ambiguous.  Compliance  with  the 
standards  varies  from  vendor  to  vendor.  The  range  of  file  transfer  protocols  is 
supported  to  varying  degrees  on  different  systems.  Higher  speed  LANs  and  WANs 
are  available;  however,  gateways  are  needed  to  combine  them  for  end-to-end 
connectivity. 
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FIG.  4-1 .  ELECTRONIC  TRANSFER  OF  DRAWINGS  IN  IGES  FORMAT 


A  gateway  in  a  CALS  network  should  not  be  viewed  as  a  single  computer 
system  that  handles  both  the  intelligent  and  the  communications  facilities.  While 
this  may  indeed  be  the  case  in  some  instances,  it  is  also  possible  that  the  gateway 
functions  may  be  distributed.  Take,  for  example,  computer-aided  design/cnmputer- 
aided  manufacturing  (CAD/CAM)  systems  at  two  different  vendors.  The  vendors 
need  to  share  their  drawings  to  integrate  their  designs  efficiently.  To  do  this,  a 
gateway  at  each  end  must  provide  a  common  data  format  for  the  drawings  and  a  path 
from  each  vendor’s  LAN  to  the  shared  high-speed  data  connection.  A  distributed 
gateway  approach  would  use  an  IGES  translator  designed  by  each  CAD/CAM 
manufacturer  for  their  system.  This  translator  would  reside  on  each  CAD/CAM 
system,  providing  the  common  data  format  required.  If  each  system  resides  on  a 
different  type  of  LAN,  the  communications  feature  of  the  gateway  would  reside  as  a 
separate  user  on  its  LAN.  As  a  separate  user,  it  would  have  both  the  LAN  and  the 
WAN  interfaces  and  file  transfer  protocols  of  each.  The  gateway  features  of 
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translation  and  communications  are  separated  by  function  as  shown  in  Figure  4-2. 
Using  this  modular  approach,  if  a  third  vendor  were  to  be  added,  the  first  two  vendors 
need  only  add  the  communications  gateway  features  required  to  connect  to  the  new 
member.  The  translation  portion  would  remain  the  same. 


FIG.  4-2.  DISTRIBUTED  GATEWAY  FEATURES 


In  the  example  shown  in  Figure  4-2,  the  IGES  translator  is  designed  specifically 
for  each  manufacturer’s  CAD/CAM  system  and  runs  only  on  its  system.  For  less 
complex  reformatting,  such  as  creating  SGML-formatted  files  from  text  files,  the 
SGML  capability  may  be  resident  with  the  communications  gateway  as  shown  in 
Figure  4-3.  The  benefit  of  this  design  is  that  a  translator,  located  in  one  place,  can 
support  input  from  a  large  variety  of  word  processing  systems.  Using  a  high-speed 
shared  gateway  greatly  reduces  its  support  and  maintenance  costs.  When  an  update 
is  required,  only  the  gateway  has  to  be  taken  out  of  service. 
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Simple  translations  such  as  SGML  reformatting  can  also  be  a  value-added 
service  provided  on  the  WAN.  Value-added  services  provided  by  WANs  include  error 
checking  and  possibly  correction,  speed  matching  between  users,  and  temporary 
storage  of  undeliverable  data.  To  add  translation  capability,  it  must  be  uncompli¬ 
cated  and  preferably  be  performed  at  the  network  node  where  the  user  connects  into 
the  WAN.  If  both  of  these  conditions  are  met,  the  impact  of  the  slower  speeds  on  a 
WAN  compared  to  a  LAN  will  be  reduced.  The  benefits  gained  from  having  the 
SGML  translation  on  the  WAN  include  sharing  the  gateway  resources  across  a  larger 
group  of  users,  billing  based  on  usage,  and  having  centrally  implemented  and 
maintained  facilities.  Placing  the  capability  in  a  gateway  on  the  LAN,  as  depicted  in 
Figure  4-3,  is  appropriate  when  the  communications  gateway  on  the  LAN  provides  a 
more  general  platform  for  integrating  SGML  than  the  dedicated  WAN  node. 
Communications  gateways  are  often  built  upon  general  purpose  computers  with  both 
a  local  and  WAN  interface.  It  would  be  easier  to  add  SGML  translation  to  such  a 
system  rather  than  modify  or  add  to  the  dedicated  systems  that  make  up  a  WrAN 
node. 

For  interactive  sessions,  the  user  at  a  terminal  logs  on  to  the  remote  system  and 
searches  for  the  desired  information.  Once  the  information  is  found,  the  user 
downloads  a  copy  to  his/her  own  system.  Intelligent  gateway  features  must  include 
automatic  remote  log-on  and  command  translation  capabilities  in  this  case.  The 
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command  translation  transforms  the  user’s  generic  query  or  request  into  the  specific 
commands  for  the  system  being  accessed. 


When  used  in  a  noninteractive  mode,  the  gateway  transmits  user  requests  to 
the  remote  system.  Upon  receiving  the  message,  the  remote  system  prepares  the 
requested  document,  such  as  a  manual  or  list  of  publications,  for  transmittal  back  to 
the  user.  In  another  scenario,  documents  will  be  transferred  on  a  prescheduled  basis 
between  systems  in  one  or  both  directions  without  the  need  for  user  involvement. 

To  send  a  document  in  either  the  interactive  or  noninteractive  mode,  the 
intelligent  gateway  must  be  able  to  analyze  the  input  to  produce  the  desired  output. 
Using  the  SGML  example  above,  the  text  file  sent  to  the  gateway  may  have  been 
stored  in  the  American  Standard  Code  for  Information  Interchange  (ASCII)  format  or 
in  a  specific  word  processing  format.  If  the  format  of  the  source  is  known,  the 
document  can  be  reformatted  into  SGML  and  be  ready  for  transmission.  The  next 
step,  determining  the  path  to  the  destination  user,  requires  a  directory  capability. 
The  desired  user  or  destination  is  matched  with  its  connectivity  constraints.  For 
instance,  the  directory  may  list  the  user’s  electronic  mailbox  on  DDN.  The  SGML 
document  can  then  be  delivered  using  the  correct  protocol  for  the  facilities  where  the 
user  is  located.  Throughout  the  process,  the  gateway  selects  from  multiple  possibili¬ 
ties  to  make  a  useful  connection  with  the  distant  user. 

Table  4-2  depicts  the  primary  locations  where  the  command  translation,  format 
conversion,  network  routing,  protocol  conversion,  and  analysis  can  occur.  Concen¬ 
trating  the  capabilities  as  discussed  in  the  SGML  and  IGES  examples  minimizes  the 
impact  to  the  systems  involved. 


TABLE  4-2 

CAPABILITY  MATRIX 


Primary 

location 

Command 

translation 

Format 

conversion 

Network 

routing 

Protocol 

conversion 

Analysis 

Sender 

X 

X 

X 

X 

Receiver 

X 

X 

LAN 

X 

X 

X 

X 

WAN 

X 

X 

X 
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CONCLUSIONS  AND  RECOMMENDATION 


5.1  CONCLUSIONS 

The  key  points  governing  the  implementation  of  gateways  in  the  near-  and  mid¬ 
term  time  frames  are  summarized  below: 

•  All  CALS  data  communications  solutions  must  be  done  in  accordance  with 
the  GOSIP.  At  the  same  time,  the  ability  to  communicate  through  the 
existing  TCP/IP  protocols  must  be  preserved.  TCP/IP  systems  will  probably 
remain  in  use  for  the  next  7  to  10  years  for  portions  of  CALS. 

•  For  other  than  occasional  usage  or  simple  text  file  transfers,  gateway 
functionality  should  be  placed  on  the  user’s  LAN  or  within  the  host 
computer.  This  approach  provides  greater  data  carrying  capacity  to  the  user 
than  placing  the  gateway  on  a  WAN.  Transmitting  data  among  different 
networks  to  reach  the  user’s  destination  may  still  require  internetworking 
facilities  such  as  those  provided  by  the  NLN  and  DAAS. 

•  SGML  for  sending  text  is  the  simplest  CALS  specification  to  implement. 
Computer  Graphics  Metafile  (CGM)  and  raster  graphics  follow  and  are 
necessary  for  the  graphics  that  accompany  the  text.  IGES  is  third,  since 
ambiguities  remain.  The  Product  Data  Exchange  Specification  (PDES)  is 
still  underdevelopment. 

•  CALS  implementation  would  be  accelerated  by  quick  resolution  of  the 
ambiguities  in  CALS  data  format  standards  as  uncovered  by  the  CTN. 
Refining  these  standards  will  reduce  the  need  for  gateways  tailored  to 
particular  implementations  of  each  CALS  standard. 

•  Intelligent  gateway  development  to  date  has  been  based  on  lower  volumes  of 
data  than  envisioned  under  CALS.  Telecommunications  planners  must 
recognize  the  high  volume  of  potential  CALS  data  traffic;  the  IGES  files 
associated  with  engineering  drawings  being  particularly  significant. 

•  Each  Service  and  agency  must  provide  a  traffic  profile  of  its  anticipated 
CALS  data  flow.  Government  network  planners  need  to  factor  these 
requirements  into  their  data  communications  planning  along  with  the  EDI 
and  MODELS  efforts.  DoD  data  network  facilities  are  primarily  operating 
at  9.6  Kbps  and  56  Kbps.  The  CALS  traffic  profiles  will  provide  the 
rationale  for  higher  data  transfer  rates. 
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5.2  RECOMMENDATION 


The  OSI/DoD  gateway  technology  developed  by  NIST  will  be  a  required 
stepping  stone  at  many  facilities.  In  addition  to  the  need  to  access  computer  systems 
through  both  the  OSI  and  DoD  protocol  suites,  CALS  data  transfers  are  made  in 
specific  formats.  Gateways  are  required  in  the  interim  to  translate  the  output  of 
current  systems  into  these  formats.  Once  the  data  have  been  formatted  correctly, 
they  can  be  sent  on  magnetic  tape,  optical  disk,  or  through  a  data  communications 
network.  For  the  data  network  connections,  a  gateway  may  be  required  for  entering 
a  higher  speed  network. 

To  meet  these  requirements,  we  recommend  implementing  gateway  technolo¬ 
gies  in  the  following  order: 

•  OSI/DoD  gateway 

•  SGML  text  format 

•  CGM  and  raster  drawing  formats 

•  Access  to  data  networks  operating  at  1.5  Mbps 

•  IGES  drawing  format 

•  PDES. 

The  OSI/DoD  gateways  are  listed  first  based  upon  our  first  conclusion.  These 
gateways  will  be  available  as  a  part  of  the  public  domain  Berkeley  UNIX  release  by 
the  end  of  1989.  As  DCA  recommends,  this  capability  should  be  added  locally  to 
increase  efficiency. 

SGML  is  listed  next  since  the  specification  has  proven  the  most  successful  in 
testing  on  the  CTN  and  is  the  simplest  to  implement.  A  gateway  allows  the 
transition  from  transmitting  data  on  magnetic  tape  or  optical  disk  to  having  a  data 
network  connection  between  users.  A  CALS  SGML  gateway  should  have  the 
following  capabilities: 

•  Translation  to  SGML  from  ASCII  and  the  most  common  proprietary  text  file 
formats.  A  commercial  off-the-shelf  (COTS)  product  should  be  used,  with  the 
requirement  that  it  keep  in  step  with  the  emerging  Portable  Operating 
System  Interface  for  UNIX  (POSIX)  profile  from  NIST.  Translation  may 
initially  be  a  two-step  process.  The  first  step  would  be  a  software  package  for 


translation  among  the  various  text  file  formats.  The  second  step  would  be 
the  translation  from  a  specific  format  such  as  ASCII  to  SGML. 

•  Local  communications  over  an  Institute  of  Electrical  and  Electronic 
Engineers  (EEEE)  802.3  LAN  for  implementations  where  the  SGML 
gateway  process  is  not  embedded  in  the  local  host. 

•  Distant  communications  connectivity  at  56  Kbps  with  the  option  to  increase 
to  1.5  Mbps  data  rates.  The  TCP/TP  should  be  used  at  first,  with  incorpo¬ 
ration  of  COTS  GOSIP  products  as  they  become  available. 

An  example  platform  for  a  UNIX-based  SGML  translator  is  the  AT&T  bundled 
product  proposed  under  the  Air  Force’s  SMSCRC.  It  offers  each  of  these  features, 
except  the  translation  from  ASCII  format  to  SGML.  The  intelligent  gateway 
ASCENT,  included  as  an  option,  provides  automated  log-on  and  connectivity.  The 
KEYpak  software  option  translates  among  the  ASCII  and  24  common  text  formats. 
The  DDN  WAN  and  EEEE  802.3  LAN  interfaces  furnish  the  distant  and  local  connec¬ 
tions. 


CGM  and  raster  capabilities  permit  transferring  illustrations.  Added  after 
SGML,  they  would  permit  the  digital  transmission  of  technical  manuals.  The  CGM 
and  raster  gateway  capabilities  would  reside  on  the  host  system  where  the 
illustrations  are  produced  or  scanned  into  the  system. 

Before  moving  on  to  IGES,  which  is  the  next  format  in  order  of  increasing 
difficulty,  high-speed  data  network  access  should  be  acquired.  Data  network  access 
at  1.5  Mbps  is  available  to  DoD  today  through  dedicated  network  facilities.  Although 
the  higher  speed  is  not  widely  used,  once  CALS  users  star,,  transmitting  documents 
in  SGML,  CGM,  and  raster  format,  they  will  soon  outgrow  the  capacity  provided  by 
56  Kbps.  This  will  become  more  apparent  as  each  of  the  Military  Services  publishes 
its  anticipated  CALS  data  communications  requirements.  COTS  hardware  is  avail¬ 
able  to  connect  the  dedicated  lines  into  local  networks  such  as  EEEE  802.3  to  provide 
the  communications  gateway.  ISDN  connectivity  off  the  LAN  should  be  added  as 
COTS  products  become  available. 

The  level  of  compliance  with  IGES  should  be  reviewed  thoroughly  in  future 
CAD/CAM  procurement.  The  translation  for  current  proprietary  CAD/CAM  formats 
into  IGES  is  probably  handled  best  by  vendors’  products  for  their  host  machines.  The 
translators  are  highly  specialized  for  each  vendor’s  product.  Once  the  data  are  in  an 
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IGES  format,  following  the  recommendations  made  above  for  SGML  and  high-speed 
data  network  access  will  complete  the  required  gateway  functionality. 

PDES  data  transfer  capability  should  be  integrated  as  COTS  products  become 
available.  The  first  translation  capabilities  will  be  located  with  the  application  as 
with  IGES.  The  communications  gateway  features  can  then  be  distributed  onto  the 
LAN. 
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ADPE  =  Automatic  Data  Processing  Equipment 

AFLC  =  Air  Force  Logistics  Command 

ANSI  =  American  National  Standards  Institute 

ARPANET  =  Advanced  Research  Projects  Agency  Network 
ASC  =  AUTODIN  Switching  Center 

ASCH  =  American  Standard  Code  for  Information  Interchange 

ATCMDS  =  Advanced  Transportation  Control  and  Movement  Document  System 
AT&T  =  American  Telephone  and  Telegraph 

AUTODIN  =  Automatic  Digital  Network 

CAD/CAM  =  computer-aided  design/computer-aided  manufacturing 

CALS  =  Computer-aided  Acquisition  and  Logistic  Support 

CDC  =  Control  Data  Corporation 

CDS  =  Central  Datacomm  System 

CGM  =  Computer  Graphics  Metafile 

CLNP  =  Connectionless  Network  Protocol 

COTS  =  coinmercial  off-the-shelf 

CTN  =  CALS  Test  Network 

DAAS  =  Defense  Automatic  Addressing  System 

DAASO  =  Defense  Automatic  Addressing  System  Office 

DARPA  =  Defense  Advanced  Research  Projects  Agency 

DCA  =  Defense  Communication'.  Agency 

DCTN  =  Defense  Commercial  Telecommunications  Network 

DDN  =  Defense  Data  Network 
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DESC 

DLA 

DLANET 

DoD 

EDI 

FDDI 

FED-STD 

FIPS 

FTAM 

FTP 

FTS 

FY 

GOSIP 

GSA 

ICP 

IEEE 

IGES 

rLes 

ILS 

IP 

ISDN 

JANAP 

Kbps 

km 

LAN 

LAP-B 

LED 


< 


=  Defense  Electronics  Supply  Center 
=  Defense  Logistics  Agency 
=  Defense  Logistics  Agency  Network 
=  Department  of  Defense 
=  Electronic  Data  Interchange 
=  Fiber  optic  Data  Distribution  Interface 
=  Federal  Standard 

=  Federal  Information  Processing  Standard 
=  File  Transfer  Access  and  Management 
=  File  Transfer  Protocol 
=  Federal  Telecommunications  System 
=  fiscal  year 

=  Government  Open  Systems  Interconnection  Profile 
=  General  Services  Administration 
=  inventory  control  point 

=  Institute  of  Electrical  and  Electronic  Engineers 
=  Initial  Graphics  Exchange  Specification 
=  International  Logistics  Communications  System 
=  Inventory  Locator  System 
=  Internet  Protocol 
=  Integrated  Services  Digital  Network 
=  Joint  Army,  Navy,  Air  Force  Procedures 
=  Kilobytes  per  second 
-  kilometer 
=  local  area  network 
=  Link  Access  Procedure-Balanced 
=  light  emitting  diode 
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LINX  =  Logistics  Information  Exchange 

LLNL  =  Lawrence  Livermore  National  Laboratory 

LMI  =  Logistics  Management  Institute 

LOGDIS  =  Logistics  Data  Information  System 

MAC  =  Military  Airlift  Command 

Mb  =  Megabyte 

Mbps  =  Megabytes  per  second 

MILNET  =  Military  Network 

MIL-STD  =  Military  Standard 

NAVSUP  =  Naval  Supply  Systems  Command 

NIST  =  National  Institute  of  Standards  and  Technology 

NLN  =  Naval  Supply  Logistics  Network 

OCONUS  =  Outside  of  the  Continental  United  States 

OSI  =  Open  Systems  Interconnection 

OSINET  =  Open  Systems  Interconnection  Network 

PC  =  personal  computer 

PDES  =  Product  Data  Exchange  Specification 

POPS  =  Paperless  Order  Processing  System 

POSIX  =  Portable  Operating  System  for  UNIX 

RFQ  =  Request  for  Quotation 

RS-232C  =  The  Electronics  Industries  Association  (ELA)  standard  interface 

between  data  terminal  equipment  and  data  communications 
equipment  employing  serial  binary  data  interchange  used  for  low 
volume  requirements  at  data  rates  up  to  19.2  Kbps 

SAMMS  =  Standard  Automated  Materiel  Management  System 

SGML  =  Standard  Generalized  Markup  Language 

SMSCRC  =  Standard  Multiuser  Small  Computer  Requirements  Contract 

SMTP  =  Simple  Mail  Transfer  Protocol 
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SNA 

SPEDE 

SQL 

TCP 

TELNET 

TISP 

TLRN 

T1 

USC/1SI 

VAN 

V.35 

WAN 


=  Systems  Network  Architecture 
=  SAMMS  Procurement  by  Electronic  Data  Exchange 
=  Structured  Query  Language 
=  Transmission  Control  Protocol 

=  The  INTERNET  standard  protocol  for  remote  terminal  connection 
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=  Technical  Information  System  Program 
=  Technical  Logistics  Reference  Network 
=  1.5  Mbps  Standard  used  in  the  United  States 
=  University  of  Southern  California’s  Information  Sciences  Institute 
=  value-added  network 

=  Consultative  Committee  on  International  Telephony  and 
Telegraphy  (CCITT)  standard  governing  data  transmission  at 
48  —  64  Kbps 

=  wide-area  network 
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